IBIS Macromodel Task Group Meeting date: 14 Aug 2012 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: * David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy Ansys: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: Michael Mirmak Maxim Integrated Products: Mahbubul Bari Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff * Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski QLogic Corp. * James Zhou Sigrity: Brad Brim Kumar Keshavan Ken Willis SiSoft: * Walter Katz Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad prepare example BIRD 125 IBIS file set - not done - Bob to propose a simpler way for addressing the needs of parameter passing under [External Model] and [External Circuit] - not done ------------- New Discussion: Walter showed a presentation "IBIS-ISS Package Modeling Discussion": - This is already on the web site - slide 2: - Walter: Would like to have open discussion, hoping to answer questions today - slide 3: - Walter: Do we need supply voltages? - Do we need XY coordinates? - The NEXT/FEXT discussion was confusing, there is a better way to describe this - slide 4: - Walter: What voltage should be applied to the package pin? - Bob: IBIS already addresses this - It is specified at the model - Randy: [Pin Mapping] specifies this - Walter: Two models could be connected to VDD with different voltages - slide 5 & 6: - Walter: XY is more reliable than CAD net name or pin number - Coordinates help generate package and die models, but are not needed in them - Arpad: IC vendors should know what the die and package look like by the time they have IBIS - slide 7: - Walter: Someone said [Pin Mapping] should not be used - This proposal is to give power and ground signal names in the models - Arpad: BIRD 145 is similar - slide 8 & 9: - Walter: A hierarchical numbered port description scheme is better than positional port names - This distinguishes between pins and pads - slide 10: - Walter: Here is an example using model names and polarity - I will post corrections to this slide - slide 12: - Walter: Multi-channel coupling can be described with Channel and Victim parameters - Supply names like VDD are given here too - Radek: Does this give the model name like the [Component]? - Walter: No this is a package model - slide 13: - Walter: This format can be use to specify sparse ports to extract from an s1000p - Walter: We can have questions here - James: How do we map pin to die pad? - Power pins map many to many - Walter showed a [Pin Die Data] example from his previous presentation - Walter: This shows how implicit die pad names allow for that mapping - James: Does this work for power? - Walter: Many old IBIS files have NA for all power pins - The [Supply Die Data] slide shows many to many mapping - Walter showed the Rambus example to explain further - Ambrish: Could smaller channels make more use of the crosstalk info? - Walter: Package models are made by interface, quadrant, bank, whole package etc. - No one simulates the whole package - Ambrish: In IBIS we mostly care about channels - Walter: We must decide what needs this satisfies and which to support - Randy: Is there a way to handle multi-die? - This is badly needed - Walter: That is the next step, we can modify EBD - I proposed EMD a few years ago, it should be easy to add the new features to EBD - Greg: The intention is to support existing and new models? - Walter: Existing IBIS does not have IBIS-ISS - Greg: It seems this is about helping to extract from boards - Walter: This is not about that - Walter: There may be too much functionality listed here - Next we must decide how to proceed - BIRDs 125 and 145 may or may not have all that is needed - My approach is model based, not pin based - A model can give data that applies to many pins - In BIRD 125 the on-die model calls the buffer models - Here the die is just between the existing models - James: More details would be needed to compare this to Arpad's proposal - Walter: Yes, much work is needed once we choose a path - James: It needs to be organized so models from different companies/divisions can work - Walter: The interfaces are all by pin/model/die names - Arpad: Do we need to decide syntax or functionality - Walter: Functionality - The syntax could be keyword or parameter trees - Parameter trees can be very powerful - Arpad: BIRD 125 could be extended to cover all of this - So syntax is the only difference - The questions are about large s-params, XY coordinates, voltages - Walter: I have been unable to see how to extend BIRD 125 - Arpad: The question is if we need all this functionality - Walter: We could vote feature by feature next week - Arpad: One general purpose syntax might satisfy all of them - Questions could be whether we want RC circuits, LC circuits, etc. - We do not need to choose because IBIS-ISS can do all of them - Ambrish: It would be good to have the voting list emailed in advance AR: Walter email a list of package modeling features for voting ------------- Next meeting: 21 Aug 2012 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives